Using a Web Application on a fortigate via jump issues a CORS error and does not work

[Atroskelis]

Expected behavior:

Web App on fortigate mgmt should open mgmt

Current behavior:

Errors in console :

Access to manifest at 'https://:6060/web/launch/.?path=%2Ffavicon%2Fsite.webmanifest' (redirected from 'https://.:6060/favicon/site.webmanifest')

from origin 'https://.:6060' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

It seems that it tries from firewall.teleport.example.com to access something teleport.example.com

Bug details:

• Teleport version - 15.4.9
• Recreation steps
• Debug logs

I've tried using many variants of rewrite but nothing works

    headers:
    - "Origin: https://<frw>.<hq-teleport>" # Teleport application subdomain prepended with "https://"
    - "Host: <frw>.<hq-teleport>" # Teleport application subdomain itself
    redirect:
    - "<frw>.<hq-teleport>:6060"

Any feedback is appreciated.

[webvictim]

Your Origin and Host headers should reference the Teleport version of the URL (https://firewall.teleport.example.com and firewall.teleport.example.com respectively) while the redirect line should reference the underlying app URL, e.g. firewall.internal or similar.

You also don't need a port on the redirect.

[Atroskelis]

Hello,

It seems no matter what i put in the headers, it doesnt seem to make a difference.

I've also tried this, and removed the redirect.

    - name: "client-frw"
      uri: "https://172.16.31.1/"
      public_addr: "client-frw.teleport.hq.ro"
      insecure_skip_verify: true
      rewrite:
        headers:
        - "Origin: https://client-frw.teleport.hq.ro" # Teleport application subdomain prepended with "https://"
        - "Host: client-frw.teleport.hq.ro" # Teleport application subdomain itself

The CORS error is still there

[Atroskelis]

Maybe it is relevant, as i have little knowledge about this, but we also had difficulty using a proxypass for fortigates as the return content was always with the IP of the fortigate and not with the IP of the host doing the proxypass

[webvictim]

It's almost definitely related. Unfortunately Teleport doesn't implement body rewrites on content that passes through it, and some systems are just built in a way that makes them quite incompatible with reverse proxying. It seems like Fortigate's web UI is one of these systems.

[Atroskelis]

One year later,

with 16.4.x which features CORS redirect, this still doesn't work:

Pseudocode:

- name: firewall
    uri: https://172.31.0.130
    public_addr: "firewall.mgmt.com"
    insecure_skip_verify: true
    rewrite: ## even rewrite headers has no apparent effect
      redirect:
      - "firewall.mgmt.com"
    cors:
    # Specifies which origins are allowed to make cross-origin requests.
      allowed_origins:
        - 'https://mgmt.com'
        - 'https://firewall.mgmt.com'
    # HTTP methods that are allowed when accessing the resource.
      allowed_methods:
        - 'GET'
        - 'POST'
        - 'PUT'
        - 'DELETE'
        - 'OPTIONS'
    # HTTP headers that can be used during the actual request.
      allowed_headers:
        - 'Content-Type'
        - 'Authorization'
        - 'X-Custom-Header'
    # Headers that browsers are allowed to access.
      exposed_headers:
        - 'Content-Type'
        - 'X-Custom-Response-Header'
    # Indicates whether the request can include credentials.
      allow_credentials: false
    # Indicates how long (in seconds) the results of a preflight request can be cached.
      max_age: 3600

After more investigation it seems the rewrite redirect is not working as requested. Possible relation to #43280 ?

URL requested is https://firewall.mgmt.com/favicon/site.webmanifest
I get a 302 FOUND
URL Location is https://mgmt.com:443/web/launch/firewall.mgmt.com?path=%2Ffavicon%2Fsite.webmanifest

hence the CORS error

[webvictim]

The redirect is being caused because Teleport isn't receiving the cookie which is set for the dc-frw-hosting.teleport.mgmt... domain, so it thinks it needs to re-authenticate.

I'm confused - the public_addr in your config above is firewall.mgmt.com but your actual URL in the screenshot is the dc-frw... domain - which is correct?

[Atroskelis]

I dont know how to debug the cookie part, should i use the debug app?

This is the last code i tried and got the same result:

[webvictim]

Try this config:

apps:
  - name: "dc-frw-hosting"
    uri: "https://172.31.0.130/"
    public_addr: "dc-frw-hosting.teleport.mgmt.domain"
    insecure_skip_verify: true
    rewrite:
      redirect:
      - 172.31.0.130
      headers:
      - "Origin: https://dc-frw-hosting.teleport.mgmt.domain"
      - "Host: dc-frw-hosting.teleport.mgmt.domain"

Replace mgmt.domain with your actual domain.

[Atroskelis]

Behaves the same. I appreciate your efforts in this incident !

Initially i thought the websitemanifest is needed for successful login to the device, apparently it is not(different browser doesnt request manifest). As such you can login but then a different matter happens:

A file is requested but Teleport gives a 401 for some reason,

But for a different file in the same path it doesn't, though the cookie exists!

Upon more experimentation, the end firewall does give a 401 for that file if you don't authenticate so it seems the issue is teleport not delivering the login credentials/auth to the firewall in order to get the file.

[Atroskelis]

Bonus: Stack trace in teleport logs: